CPU design is all about the tradeoff between size, complexity, speed and power consumption.

First, I'd just go with a MIPS core. This is effectively the original RISC core, after all. Most patents have expired, and the Chinese have an implementation.

If I didn't do that, I'd probably go with a DEC Alpha core. A shrunk, voltage optimized Alpha core was what drove the StrongARM series, and people raved about it. The Alpha architecture up through EV5 is quite clean.

I scan-read the paper, but did not encounter any number of registers. Does anybody know, how many registers this architecture has/supports ... is there any implementation yet?

Hope, there will be an implementation soon, and maybe a smartphone or tablet computer based on it... (or a new Raspberry?)

I'd argue that's part of why it's been so successful, especially in competition with the other big ISA - x86. Complex instructions are good because they do a lot in a small size, and a small size is good because it conserves cache usage and memory bandwidth; decoding is rarely the bottleneck now. That's why ARM has Thumb, and their latest cores are similar to x86's uop-decoding and decoupled decoder/execution units.

The whole "it can be done faster in software" idea of RISC was mainly based on some early CISC microarchitectures that weren't implemented as efficiently as they could be, which doesn't imply that they couldn't be. Look at all the instructions added by the various SSE extensions, for example; the performance/speed improvements they provide are real, and the cost of the hardware is basically negligible in comparison.

These have changed throughout history, e.g. when I was reading the Wikipedia CDC 6600 page, it pointed out magnetic core memory of the time could be much faster than germanium transistor CPUs (we're talking about the days when transistors had serial numbers!), and the silicon ones it were built with were fast enough that, with clever architecture (a 60 bit floating point multiply or divide still took many more cycles than a fast memory cycle) and compilers, a theoretical 3 MFLOPs resulted in an achievable 0.5 MFLOPS in FORTRAN. My first job in 1980 was supporting applied mathematicians who ran their FORTRAN on CDC and CRAY hardware at NCAR a couple of thousand miles away. One thing they were always concerned with was to write their array manipulations in a way that the compiler recognized to use the vector hardware.

Also on this topic: if the original MIPS was indeed very simple, recent versions added thumb-like code compression, SIMD extensions, DSP extensions... As everyone else does really. And you can get similar CPU benchmarks level as other architectures. Then the very same instruction architecture can have pretty wide power efficiency differences depending on implementations. Just look at Atom vs. Core, A8 vs. 15... Even the same model shows big differences based on implementation choices (optimize for speed vs. area/cost for example).

More from the page, enough to get me interested:

On performance: "As a rough guide we would expect ~500-1GHz at 40nm and ~1.0-1.5GHz at 28nm."

Is volume fabrication feasible?

Yes. There are a number of routes open to us. Early production runs are likely to be done in batches of ~25 wafers. This would yield around 100-200K good chips per batch. We expect to produce packaged chips for less than $10 each.

Looking at this slide show: https://speakerdeck.com/asb/lowrisc-a-first-look I see they're doing some very interesting things. Besides a lot of usual stuff, 2 cores each with I+D L1 and a shared L2 cache, they've added tags!

2 bits of tags, and they're thinking general purposes (e.g. GC) as well as security. That's big, something we haven't seen in hardware since Lisp Machines, to my knowledge.

Also I/O "minions", non-coherent RISC-V cores, like the CDC 6600 etc.

The IBM AS/400 or whatever it is called this week uses tags too for security. (A bit is flipped if a pointer is written too thereby preventing changing pointers.) The PowerPC chip has optional support for tags because of this.

Read and write barrier instructions could be very nice for GC, but those can be done at the page level, I think (I would look at the Azul's Pauseless collector for one state of the art custom hardware approach, and their C4 for doing without on x86_64).

But I'm more interested in tags for dynamically typed languages like Lisp. You don't need many bits, Symbolics used only 4 "hard" ones in the 36 bit 3600 line, which allowed for immediate 32 bit integer and floating numbers, then another 4, leaving 28 bits for word based addressing.

In modern byte addressed CPUs, you can use the least significant bits that are 0 in a pointer for tagging, so the 2 "hard" bits you propose are enough to work with. Basically, as long as we don't have to box floats!

Although it would be nice if we could set things up so that e.g. floating point operations could proceed at full speed, generating a fault if the tag bits on the operands aren't correct ... although superscalar CPUs can do both in parallel without "hard" tags. Are your two main cores going to be superscalar?

And I guess to finish my wishlist, a potential for a lot of ECC DRAM would be nice, at least 16 GiB.

"We did not include special instruction set support for overflow checks on integer arithmetic operations. Most popular programming languages do not support checks for integer overflow, partly because most architectures impose a significant runtime penalty to check for overflow on integer arithmetic and partly because modulo arithmetic is sometimes the desired behavior."

!!!

Or, RISC-V is a Worse is Better (https://en.wikipedia.org/wiki/Worse_is_better), New Jersey style processor, following the same exact model of the primacy of implementation simplicity.

Well, especially since we aren't going to get people to use "safe" languages prior to e.g. software errors killing 4-6 figures of people, I guess it's a really good thing you're adding tag bits that can be used to improve security in unsafe languages.

On the other hand, as a CPU for The Right Way operating systems and languages like Lisp, RISC-V would seem to be ... subpar, especially since who knows what other corners have or will be cut. (Yeah, I know you can check, and for Lisps, it would be fairly cheap to have fixnums be 32 to 29 bits (subtracting LSB bits for more tagging) and then promote them to bignums, but....)

It's useful for several things. One is as a no-op instruction; as you point out, AND, OR, XOR, etc. with zero are no-ops, and no-ops are sometimes useful for achieving certain alignment in code, or leaving space for instructions to be patched out with other code (which is common for debugging, tracing, and hot-patching of code).

It can also be used for copying from one register to another, without another instruction. "ADD rd, rs1, 0" is a way to write "MOVE rd, rs", so you don't need to waste an extra instruction on that.

0 is also one of the most common values that you want to compare against (many loops can be turned into decrementing a value until it becomes zero, or you're just walking along a data structure or string until you encounter a null value), and so their branch instructions work by comparing two registers and branching to a particular offset. Having a dedicated 0 register means you can always do a compare against 0 and branch in a single instruction, without having to have separate instructions for comparisons against immediates versus comparison of two registers.

For example, the original MIPS instruction set has these pseudoinstructions:

- li $d, imm (load immediate) is replaced with ori $d, $0, imm (or immediate with the zero register)

- not $d, $s (bitwise complement) is replaced with nor $d, $0, $s (bitwise NOR with the zero register)